Predicting future values of parameters is desirable in many fields and endeavours, including molecular biology, oil and gas, structural engineering, financial modelling and weather forecasting. Typically, in these fields, the value of the parameters is dependent on a complex relationship between several underlying variable factors and sub-variables. Forecasting (i.e. determining future potential events with a probability associated with each of them) is useful as decisions and expectations can be made based on predictions. Also, such predictive analysis can result in useful feedback being provided to a control system to configure a system or device to accommodate the future state or events.
Predictive functions using approximation techniques are used in situations where a given parameter can only be determined by consideration of a group of functions where each function is determined based on multiple scenarios. The scale of computational effort required for this future behaviour simulation is so large, for example there may be millions of variable values requiring millions of approximation calculations, that even current state of the art computing platforms struggle to meet the desired level of accuracy and performance. For example, current forecasting systems may reduce the number of approximation calculations performed, thus reducing accuracy, or increase the amount of processing power used, thus increasing the electrical power and resource requirements of the system. The application of such predictive analysis techniques includes fields such as structural engineering, molecular biology weather forecasting, oil and gas and financial modelling.
For example, in biomedical and biological research, it is of the utmost importance to determine the behaviour of molecules in complex systems. Thus simulation of molecular interaction is essential to predict the results of variable changes that may affect the systems where molecules lie, such as the interactions of a drug with its solvent, or the receptors where it binds. When working with simple molecules standard statistical methods suffice, but in the case of complex molecules such as DNA, proteins or RNA, molecular simulation methods require the inclusion of variables that affect, in apparent serendipity, the global behaviour of biological systems.
Complex simulation can be used, for example, to predict how a protein folds in space, how a membrane receptor transports the ligand to the cellular cytoplasm, how this receptor interacts with the ligand to elicit a physiological response, or how the viral conformation changes to bind to the host membrane and successfully infect it. Complex simulation and prediction systems are in many cases based on the Monte Carlo method, amongst other methods. Furthermore, the Monte Carlo method has been used to simulate and predict evolutionary changes using molecular data from different species.
Further, the folding of chains of protein atoms into shapes that make them usable can be modelled. This modelling can be done using the Monte Carlo method in a simulation (i.e. a Monte Carlo simulation), where each time step simulates a random step forward, and then the equations that create the point of electro-magnetic equilibrium are solved as is known in the art. These equations are extremely complex to calculate and use a significant amount of computing resource.
In structural engineering, for example, for a car manufacturer, there are generally very complex and accurate models that can be used to determine the stress and damage that each component of the car may receive. It is desirable to understand how long a car would last without a component failing in different driving conditions in order to optimise the design and interaction of the components. Different driving scenarios can be simulated over different periods of time (e.g. city driving, on the highway, in the countryside, a combination of city and countryside, at different speeds, etc.). The model can then be used to determine the incremental damage to each component of the vehicle until the damage reaches a threshold of stress that would cause the component to fail. By running these simulations it can be understood how long, on average, the car could remain roadworthy, the probability of it breaking in 1 year, in 5 years, in 20 years, etc.
Typical Prior Art Forecasting System
In the examples described above, the underlying variables that affect the desired parameter may be determined using stochastic modelling such as the Monte Carlo method. The stochastic models can then feed into the determination of the desired result, as the complex relationship between the result and the underlying variable factors is known. However, in order to achieve more accurate results, more combinations of the underlying variables must be run. This becomes computationally very expensive, especially when increasing the number of iterations.
A typical prior art forecasting system 10 is shown in FIG. 1. The forecasting system 10 is suitable for applications wherein the underlying variables that affect the desired parameter may be determined using stochastic modelling. The features of the forecasting system 10 are described in general terms here, and in example contextual applications below. The forecasting system 10 comprises a controller 12, an input factor module 14, a scenario module 16, a metric module 18 and an input/output module 20. The input factor module 14, the scenario module 16, the metric module 18 and the input/output module 20 are each connected to the controller 12.
The input factor module 14 determines the different scenarios 21 (i.e. stochastic models) of the underlying variables that feed into parameter functions 25 (discussed in greater detail below). The input parameter scenarios 21 are stored in a stochastic model database 22.
The metric module 18 is arranged to calculate metrics 19 to generate a forecast based on the evaluated parameter functions 25. The input/output module 20 provides an interface with the forecasting system 10 to external parties. For example, values of the input variables may be provided by a user or an independent system via the input/output module 20.
FIG. 2 shows the scenario module 16 in greater detail. The scenario module 16 comprises a parameter function evaluator 24 and a parameter function database 26 each connected to a scenario controller 28. The parameter function evaluator 24 is arranged to evaluate parameter functions 25 using input variables from the input factor module 14 to generate forecast scenarios 27.
The parameter function database 26 comprises a plurality of application-specific parameter functions 25. Inputs to the parameter function are a set of one or more variables from the input factor module 14. When the parameter function is evaluated for values of the set of one or more variables, the output of the parameter function is a value of the parameter at the given values of those variables.
FIG. 3 shows the relationship between the input scenarios 21, the underlying variables that create the scenarios (in this example, two variables), one of the parameter functions 25 (in this example, function F2), the forecast scenarios 27 and the metrics 19. Namely, each scenario is defined by a different combinations of values of the underlying variables. These scenarios are the input to the function F2 used to generate outputs. The outputs of F2 are the forecast scenarios 27 which in turn can be used to determine metrics 19.
FIG. 4 shows a flowchart summarising the prior art process 30 carried out by the forecasting system 10 described above in relation to FIG. 1. The process 30 begins with all the input variables for the parameter function being evaluated at Step 32 by the input factor module 14 using stochastic modelling and being stored in the stochastic model database 22.
Using the input variables as inputs to the parameter functions 25, the parameter scenarios are determined at Step 34 by the scenario module 16. The parameter scenarios also vary stochastically but are different to the stochastic models of the input variables. The parameter function evaluator 24 of the scenario module 16 evaluates the appropriate parameter function 25 from the parameter function database 26 as many times as required to determine the desired parameter scenarios. The parameter function to be used for the forecast is typically predetermined.
Metrics 19 are then evaluated at Step 36 by the metric module 18 taking input from the parameter scenarios generated by the scenario module 16. The prediction or forecast can then be generated at Step 38 using the metrics determined at Step 36. The output of the forecast may be a probability of an event occurring.
The forecasting system 10 is described in greater detail below in the context of the oil and gas industry, weather forecasting and financial modelling. The oil and gas and weather forecasting examples are described with reference to the typical prior art forecasting system described with reference to FIGS. 1 to 4.
Oil and Gas
In the example of oil and gas industry, the process 30 carried out by the forecasting system 10 involves the input factor module 14 evaluating at Step 32 the stochastic models for input variables. The set of input variables may include: viscosity of the crude oil, remaining supplies in the oil reservoir, oil pumping capacity, well temperature, availability and/or effectiveness of drilling fluid which each vary stochastically over time. The different scenarios 21 (i.e. the stochastic models) for each of the input variables are stored in the stochastic model database 22.
The parameter function database 26 of the scenario module 16 in this example stores a parameter function 25 to determine the extractable volume of crude oil in an oil well over time. The scenarios 21 of this parameter are determined at Step 34 by the scenario module 16 using the input variables from the stochastic model database 22. The parameter function is evaluated at each time step in each scenario to form a stochastic model of the extractable volume parameter.
Metrics are then determined by the metric module 18 at Step 36 based on the expected volume of crude oil that can be extracted from the oil well. In this example, the metrics 19 may include required oil refinement and purification capacity and staffing levels required in downstream processes. The calculated metrics 19 allow the forecast to be generated at Step 38, for example the probability of the future refinement and purification demand exceeding current capacity. Accurate forecasts are beneficial to enable refinement and purification capacity to be increased in a timely manner to meet the predicted demand making the refinement and purification process more efficient.
For the metric of staffing level required, accurate forecasts are advantageous in determining whether additional or fewer staff need to be employed to meet the production demand of the oil well.
In order to improve the accuracy of the forecast, the time resolution of the parameter function scenarios determined at Step 34 is increased. However, the typical time to evaluate the parameter function 25, combined with the number of times the parameter function 25 is evaluated for each scenario 21 means that an accurate high-resolution stochastic model for the extractable volume parameter generally may take a long time to generate even using systems employing the highest power computing devices available. If the time taken to generate the parameter function scenarios is too long, the results may no longer be valid as the value of the starting conditions may have changed.
In order to generate the stochastic model for the extractable volume parameter in a timely manner for the forecast, prior art forecasting systems 10 generally undertake one or more of the following:
1) Reduce the number of scenarios and time points determined at Step 34 by the scenario module 16, so the calculation can be done in a reasonable time. However, the disadvantage is that this reduces the resolution of the scenarios and decreases the accuracy of the metrics used to generate the forecast;2) Not attempt the calculation of complex parameter functions, as these would utilise more computational time. Again, as a consequence, the determined metrics would be negatively affected by a decrease in accuracy; and3) Increase the number of computers (and hence computational power) configured to implement the forecasting system 10. However, the number of computers required to reduce the time required to ensure that the results are valid and useful, can be completely impractical. Accordingly, even with increased computing power, the results still suffer from a low resolution and poor accuracy.4) Implement shortcuts in the methods of the calculation that may increase the speed, but that are always at the expense of accuracy in the calculation. As a result, the accuracy and usability of the metrics generated is compromised.Weather Forecasting
Another example application of the forecasting system 10 is in the field of weather forecasting. When predicting the temperature or rainfall in a location at a particular time, the temperature or rainfall can be predicted using parameter functions where the set of one or more input variables may include air pressure, air density, solar energy and humidity each from hundreds or more different locations. Monte Carlo simulations are used for weather prediction, starting with the state of the atmosphere when the conditions (e.g. temperature, humidity, pressure) are known.
The process 30 carried out by the forecasting system 10 begins at Step 32, wherein the input factor module 14 determines the variation over time for the input variables across a plurality of scenarios 21. The different scenarios 21 of the variation over time (i.e. the stochastic models) for each of the input variables are stored in the stochastic model database 22.
In this example, the parameter function database 26 includes a parameter function 25 which outputs the temperature at a geographic location as a function of one or more of the input variables. The scenarios 21 of this parameter 25 are determined at Step 34 by the scenario module 16 using the input variables from the stochastic model database 22. The parameter function 25 is evaluated at each time step in each scenario 21 to form a stochastic model of the temperature.
Metrics 19 are then determined by the metric module 18 at Step 36 based on the expected temperature variation at the geographic location. The metrics 19 may include, for example, sea level, pollen count, UV index and wind speed/direction. The calculated metrics 19 allow the forecast to be generated at Step 38. For example, the wind speed and direction metric may be used to determine the probability of the wind speed exceeding a predetermined threshold above which precautionary measures would need to be taken by public services in a timely manner. Another example is if the probability of the pollen count or UV index exceeding a predetermined threshold. The forecast can be publicised to the general public to enable them to take appropriate action.
In weather modelling, as well as in oil and gas, accurate forecasts are advantageous. The accuracy of the metrics 19 is dependent on the resolution of the parameter function scenarios 21 determined at Step 34. However, the typical time to evaluate the parameter function 25, combined with the number of times the parameter function 25 is evaluated for each scenario 21 means that an accurate forecast generally takes a long time to generate. One problem is that if the time taken to generate the parameter function scenarios is too long, the results may no longer be valid as the known value of the starting conditions (from which the input parameters are generated, and that may be included in the input parameters) may have changed.
The parameter function database 26 may also include a parameter function 25 arrange to output the state of equilibrium in the atmosphere, such that a scenario shows the evolution of the atmospheric conditions. Typically, this parameter function is evaluated at Step 34 with small time steps in the Monte Carlo simulation, and after each time step, the state of equilibrium in the atmosphere is determined before the next time step. The smaller the time steps, the easier it is to solve the equations that describe the new state of atmospheric equilibrium. However, with a smaller time step, it becomes computationally expensive to run the simulation far into the future (i.e. a longer time frame). Therefore, to be able to predict further in time in the simulation, larger time steps are used in the simulation. However, these larger time steps make the equations that calculate the new atmospheric equilibrium point more complex and therefore more difficult to solve.
In order to generate the parameter function scenarios in a timely manner for the forecast, prior art forecasting systems 10 generally undertake one or more of the three options expressed above, namely:
1) Reducing the number of scenarios and time points determined at Step 34 by the scenario module 16;
2) Simply not attempting the calculation of complex parameter functions; and
3) Increasing the number of computers (and hence computational power) configured to implement the forecasting system 10.
4) Implementing shortcuts in the methods implemented that may increase the speed, but that decrease the accuracy of the calculation.
Often, none of the above lead to a satisfactory solution that is as accurate as desired.
Financial Modelling
A more detailed but functional example of forecasting is discussed below in the field of financial modelling to illustrate the limitations of existing state of the art forecasting simulation technology. However, it is to be appreciated that the technical limitations which exist in the implementation of these systems and techniques apply equally to all fields of application of forecasting and simulation technology.
Taking finance as a specific example, Over-The-Counter (OTC) derivatives are significant part of the world of global finance. OTC derivatives are contracts signed by two institutions by which they agree to exchange a series of cash-flows during and/or at the end of the contract. Those cash-flows will be driven by the value of some specified external variables. Both institutions agreeing to these contracts are typically called the tounterparties' of the OTC derivative. A financial institution may comprise a large number of OTC derivatives in a ‘portfolio’ or ‘book’, with typically up to of a few million OTC derivatives.
Each OTC derivative comprises one or more price parameters. Examples of price parameters include: a value of the price, a time validity of the price and a potential variation range (e.g. a standard deviation) of the price, a sensitivity of the price to external factors (e.g., the so-called “Greeks” in the art).
An example of a contract is an Equity Future. In this example, today is 1 Jan. 2014 and entity A and entity B agree to the following cash-flow between them on 1 Jan. 2015: the difference in the value of SP500 on those two days, multiplied by an agreed notional value. Accordingly, they agree that a price parameter, P, of the contract is approximately determined by:P=Notional(SP5001jan15−SP5001jan14)where Notional is, for example, one thousand US Dollars, and SP500 is the value of the Standard & Poor's 500 equity index such that SP5001jan14 is the value on 1 Jan. 2014 and SP5001jan15 is the value on 1 Jan. 2015. If P is greater than 0, then entity A receives the cash-flow from entity B, if P is less than 0, then entity A pays the cash-flow to entity B.
It must be noted that the price parameter and risk management of these assets, which have a value that changes constantly and, often, very rapidly, is a major issue for asset owners. The reason for this is that the evaluation of accurate risk metrics can be highly computationally demanding to the extent that, in many cases, it cannot be carried out properly. This will be explained in more detail in this document. Furthermore, calculation of price parameters and risk metrics demands the valuation directly from market data using price parameter functions.
This contract has a price parameter at any time, t, between 1 Jan. 2014 and 1 Jan. 2015, which can be approximated by:Pt=Notional(SP500t−SP5001jan14)
Generalizing the example above, in order to calculate the price parameter of an OTC derivative at any point in time, there are two distinguishable components:
1) Risk Factors
The price parameter of an OTC derivative is based in the value of several risk factors. In the simplified example provided above, there was only one risk factor, the value of the SP500 equity index. However, in most OTC derivatives, there are a substantially greater number of variable risk factors. These risk factors include several types of interest rates, foreign exchange rates, equity prices, credit spreads, commodity prices, bond prices, etc. A financial institution's book of OTC derivatives will be sensitive to a plurality of these factors, typically ranging from a few hundred to several thousand risk factors.
2) Derivative Price Parameter Functions
Once the risk factors that affect the price parameter of the OTC derivative have been determined, the price parameter at time t will be given by a function ƒ(x), such that:Pt=ƒ(xt)where x refers to the weighted and combined collection of all the risk factors that are relevant to the price parameter of that OTC derivative at time t. Referring back to the previous example, if x is taken to be equivalent to SP500, then ƒ(xt)=Notional (xt−x0), where x0 is the initial value of the risk factor, i.e. SP5001jan14.Determination of Counterparty Credit Risk Metrics
In the context of financial services, counterparty credit risk is the risk that a counterparty to a financial contract will default prior to the expiration of the contract. As OTC derivatives are generally privately-negotiated contracts between counterparties, they are subject to counterparty risk. Counterparty risk is similar to other forms of credit risk in that the cause of economic loss is if the obligor defaults (e.g. goes into liquidation). However, counterparty risk is differentiated from more conventional forms of credit risk in the uncertainty of exposure (i.e. the value of the potential loss may vary) and its bilateral nature (i.e. both parties are exposed to each other). In order to reduce the uncertainty of exposure and manage the counterparty credit risk, the risk is measured and quantified using one or more metrics.
FIG. 5A shows an example prior art forecasting system 100 that can be used to determine counterparty credit risk metrics. The system comprises a controller 102 and a risk factor module 104, a price parameter module 106, a risk metric module 108 and an input/output module 110 that are each connected to the controller 102. The risk factor module 104 determines the variation over time of the underlying variables that feed into the price parameter functions and affect the price of the OTC derivatives.
A price parameter function, ƒ(x), is a mathematical function that defines a relationship between one or more input variables to produce an output, where the output is a parameter of the price. Price parameter functions are defined in the domain(s) of the one or more input variables. Accordingly, a price parameter function varies in one or more relationship domains (as opposed to the time domain) where each relationship domain corresponds to the effect of the one or more input variables on the output of the function.
The risk factor module 104 stores data regarding the value of the risk factors in a stochastic model database 112, described in more detail with reference to FIG. 5B. The price parameter module 106 determines the price parameter function ƒ(x), and is described in more detail with reference to FIG. 6A. The risk metric module 108 is configured to determine the value of the counterparty credit risk metrics. The input/output module 110 provides an interface with the forecasting system 100 to external parties.
Each module comprises its own processing core or set of processors arranged in parallel with a multicore structure to provide increased processing speed as is known in the art. The input/output module 110 is configured to allow two-way communication between the forecasting system 100 and a user (user device or computer) or computer network, wherein inputs are signals or data received by the system, and outputs are signals or data sent from it. For example, the input/output module 110 may be a network card, a modem or a computer terminal comprising a keyboard and a monitor.
FIG. 5B shows the stochastic model database 112 in greater detail. For each risk factor 114, for a point in time 116, values 120 of the risk factor are stored for a plurality of different scenarios 118. In the example of FIG. 5B, the values 120 of two different risk factors, Factor1 and Factor2, are shown each at four time points.
FIG. 5C is a graphical representation of an example stochastic model 122 that may be stored in the stochastic model database 112. The stochastic model 122 shows the value of a risk factor over time with four distinct distributions of potential outcomes 124, called ‘scenarios’. In the example shown all four scenarios 124 start at t=0 with the same value of the risk factor; however it must be noted that, in other applications, this may not always the case and the initial value of the scenarios may be different. In FIG. 5C, only four scenarios are shown for illustrative simplicity, however, a typical stochastic model may comprise thousands of scenarios.
In this example, the initial conditions of each risk factor are known, in other words, the value of each risk factor is known for the present time, t=0, however the values of the risk factor any time after the present time are not known. As each risk factor may vary over time, the risk factor module is configured to determine the evolution of the risk factors over time using probabilistic modelling in the form of stochastic simulation such as the Monte Carlo method as is known in the art.
The four scenarios 124 tend to diverge away from each other with increasing time as the stochastic model allows for random variations which accumulate, causing increased uncertainty in the potential future value of the risk factor. The random variations can be based on fluctuations observed in historical data of the risk factor and/or in the value of current data.
As described above, each OTC derivative may be affected by a few hundred to several thousand risk factors, each with their own stochastic model of value for thousands of scenarios.
The stochastic scenarios generated by the risk factor module 104 are communicated to the price parameter module 106 via the controller 102.
The price parameter module 106 is configured to determine the price parameter of each OTC derivative at a desired time point and in a given scenario. For a particular time, t, and in a given scenario, i, the price parameter of the OTC derivative can be determined using a pricing parameter function, Pt,i=ƒ(xt,i). To establish the variation of the OTC derivative price parameter over time in a given scenario, the pricing parameter function can be determined for different points in time.
FIG. 6A shows an example prior art price parameter module 106 in greater detail. The price parameter module 106 comprises a price parameter controller 150, a price parameter function evaluator 152 and a pricing function database 154. The price parameter controller 150 is connected to the controller 102 of the forecasting system 100. The price parameter function evaluator 152 and the pricing function database 154 are each connected to the price parameter controller 150. The price parameter function evaluator 152 determines the value of a price parameter function from the pricing function database 154 using the value of the risk factors from the stochastic model database 112. The pricing function database 154 comprises a plurality of price parameter functions.
FIG. 6B shows the pricing function database 154 in greater detail. The pricing function database 154 stores the price parameter function 156 associated with each OTC derivative 158 in the financial institution's portfolio. Each price parameter function 156 generally comprises a different combination and weighting of risk factors. The price parameter function evaluator 152 is configured to determine the output value of the price parameter function 156, requesting the value of the risk factors it requires from the stochastic model database 112 via the risk factor module 104 and the controller of the system and the price parameter controller 150.
FIG. 7A is a graphical representation 180 of an example of a price parameter function over time and shows an example distribution in the price parameter of an OTC derivative over a period of time in two potential outcomes 182 (i.e. two scenarios). The price parameters of the OTC derivative in each of the two scenarios is determined by the price parameter function evaluator 152 and are shown at each of ten time points, t0 to t9 respectively.
FIG. 7B is a graphical representation 184 of another example of a price parameter function over time showing a higher resolution distribution of four scenarios 186 compared to the lower resolution shown in FIG. 7A. The higher resolution means that the price parameter function has been evaluated at more time points.
Increasing the number of time points at which the price parameter is determined increases the resolution of the scenario, thereby increasing the accuracy of any analysis made on the scenario. However, as is described below, this comes at a far greater computational cost. This is because each determination of the price parameter function by the price parameter module 106 is computationally expensive, and the price parameter function must be evaluated at each desired time point and scenario.
The number of scenarios in the stochastic model generated by the risk factor module 104 will be referred to below as N. For example, referring to FIG. 5C, N=4. Additionally, the number of points in time at which the OTC price parameter is determined at will be referred to M. For example, referring to FIG. 7A, M=M. It follows that in a price parameter distribution, the price parameter function is determined N×M times for each derivative. For example, referring to FIG. 7A, the price parameter function is called by the price parameter function evaluator 2×10=20 times.
The price parameter distributions generated by the price parameter module 106 are communicated to the risk metric module 108 via the controller 102.
The risk metric module 108 is configured to determine a plurality of counterparty credit risk metrics using all the scenarios in the price parameter distributions for all the OTC derivatives of the financial institution. Many metrics are typically used for pricing, accounting, risk management and capital calculations. The metrics include:
a) Expected Exposure (EE) profiles, both in its ‘positive’ (EPE) and ‘negative’ (ENE) version
b) Potential Future Exposure (PFE) profiles
c) Credit Value Adjustment (CVA) and Debit Value Adjustment (DVA) for pricing
d) Effective Expected Positive Exposure (EEPE) for regulatory capital calculation
e) Funding Value Adjustment (FVA) for internal valuation and balance sheet calculation.
FIG. 8A shows a flowchart summarising the prior art process 200 carried out by the forecasting system 100 described above in relation to FIG. 5A. The process 200 begins at Step 202, where all the risk factors are evaluated using stochastic modelling by the risk factor module 104 and stored in the stochastic model database 112. Using risk factors as inputs to the price parameter functions, the price parameter scenarios (which are related but different to the risk factor scenarios) are determined at Step 204 by the price parameter module 106. The price parameter function evaluator 152 of the price parameter module 106 evaluates the appropriate price parameter function from the pricing function database 154 as many times as required to determine the desired price parameter scenarios (described in more detail with reference to FIG. 8B). The risk metrics are then evaluated at Step 206 by the risk metric module 108 taking input from the price parameter scenarios generated by the price parameter module 106. The prediction or forecast can then be generated at Step 208 using the risk metrics determined at Step 206.
FIG. 8B shows a flowchart of the process 204 carried out by the price parameter module 106 in order to determine the price parameter scenarios. The process 204 starts with the price parameter function evaluator 152 receiving at Step 210 the number of time points, M, required for the desired resolution of the price parameter scenarios. Then the price parameter function evaluator 152 receives at Step 212 the number of scenarios, N, desired. The price parameter function evaluator 152 then obtains at Step 214 the price parameter function 156, ƒ(x), for the OTC derivative from the pricing function database 154.
The price parameter function evaluator 152 sets at Step 216 the current time point to the first time point of the total number of time points, M. Then, the price parameter function evaluator 152 sets at Step 218 the current scenario to the first scenario of the total number of scenarios, N.
For the first time point of the first scenario, the price parameter function 156 is then evaluated at Step 220 by the price parameter function evaluator 152. The price parameter function evaluator 152 then checks at Step 222 whether the price parameter function has been evaluated for all scenarios N received at Step 212 for the first time point. If not, the price parameter function evaluator 152 moves at Step 224 the current scenario to the next scenario and the process 204 loops back to Step 220 whereby the price parameter function 156 is evaluated by the price parameter function evaluator 152 for the current time point.
This loop continues until the price parameter function 156 has been evaluated for all the scenarios, N, received at Step 212 for the first time point. If, following the check at Step 222, the price parameter function 156 has been evaluated for all the scenarios received at Step 212, the process 204 moves on to checking at Step 226 whether price parameter function 156 has been evaluated for all time points received at Step 210.
If not, the price parameter function evaluator 152 moves at Step 228 the current time point to the next time point and then the current scenario is moved at Step 230 to the first scenario. The process 204 then loops back to Step 220 whereby the price parameter function 156 is evaluated by the price parameter function evaluator 152 for the current time point of the current scenario. Once the price parameter function 156 has been evaluated for all the time points for all the scenarios, the process 204 is completed.
In other embodiments, all the time points for the first scenario are determined before moving on to determining all the time points for the next scenario, until all the time points for all the scenarios have been determined.
The process 204 carried out by the price parameter module 106 in order to determine the price scenarios demonstrates that the number of evaluations of the price parameter function 156 required (M×N in this example) is a limiting factor in the speed of the overall process 200 carried out by the forecasting system 100. A more detailed numerical example of the limitations imposed by the process 204 is highlighted in the financial example below.
Example Number of Price Parameter Function Determinations
Taking the CVA metric as an example, the price parameter of the OTC derivative is typically desired to be calculated to an accuracy of one ‘basis point’ (one one-hundredth of one percent), i.e. 0.01% ( 1/104). The typical number of scenarios, N, used in order to achieve this pricing error in CVA is around one million.
In order to calculate the CVA ‘Greeks’ via Monte Carlo methods (the sensitivities of the CVA price parameter to changes in the market conditions), the CVA price parameters must be calculated to a resolution of 0.01 basis points at least ( 1/106) so that the calculated Greek parameter has a stable value. As the pricing error expands in Monte Carlo simulations as √{square root over (N)}, this means that in order to calculate the Greeks to this accuracy, N would be around ten billion (i.e. 10,000,000,000) and this would be received by the price parameter function evaluator 152 at Step 212 of the process 204.
The expiry of an OTC derivative may range from a few weeks (e.g. foreign exchange derivatives) to up to 50 years (e.g. inflation derivatives). The average expiry in a financial institution's book of derivatives can typically be of around 10 years.
For example, taking an average OTC derivative with an expiry of 10 years, there are approximately 2,600 trading days in that period. Ideally, the financial institution would desire an accurate determination of the counterparty credit risk that it is currently exposed to be based on the forecast from today (i.e. to) to the end of year 10. Taking each day as a point in time at which the price parameter is determined for one of the OTC derivatives, M=2,600 and this would be received by the price parameter function evaluator 152 at Step 210 of the process 204. Therefore, in order calculate, for example, the CVA counterparty credit risk metric for this OTC derivative to the desirable degree of accuracy of 0.01 basis points, the price parameter function is determined N×M times or 10,000,000,000×2,600=26,000,000,000,000 (i.e. 26×1012 times) in the step of determining the price parameter scenarios (Step 220 of the process 204 carried out by the price parameter function evaluator 152).
A typical large financial institution may have a few million OTC derivatives on their books. For example, if the number of derivatives, D, of a financial institution is 1,000,000, then to calculate the CVA metric for each (and assuming an average expiry of 10 years for each OTC derivative), the number of times that the price parameter function 156 is determined is D×N×M times or 1,000,000×26,000,000,000,000=26,000,000,000,000,000,000 (i.e. 26×1018 times).
This number of calculations would only determine one set of risk metrics. Additionally, a number of subsequent calculations are carried out. In order to calculate the CVA Greeks via the typical Monte Carlo method, for example, this calculation would be repeated at least one time per Greek. A large financial institution may typically desire to calculate a few hundred Greeks. The example below uses 100 Greeks.
Also, whenever a new derivative is transacted, an existing derivative is unwound, or when risk analysis is performed, the calculation would be to be re-run, at least partially to the netting set affected by the derivative.
Conservatively, a typical financial institution may desirably run this calculation 10 times per day.
This would lead to the number of price parameter function determinations, in this example, to be:100×10×26×1018=26×1021 
The number of calculations required to achieve this desired level of accuracy demands significant computational effort and accordingly, takes too long to process to be of any benefit. Accordingly, this level of accuracy is simply not achievable within a practical time period given the available computing power.
Maximising the accuracy of the risk metrics is desirable in all fields, including weather forecasting and in the oil and gas industry. In turn, this increases the number of times the respective functions ƒ(x) are evaluated, requiring more computational effort and time.
Computational Power Requirements
The largest financial institutions in the world comprise server farms of state-of-the-art computers, available 24 hours a day, for these calculations. In spite of that, the reported number of scenarios that they use range between N=1,000 and N=10,000, and the number of time points between M=25 to M=100.
The computational time required for an optimised price parameter function 156 for a single parameter currently range from around one millisecond for the simplest derivatives to several minutes or hours for complex ones. Reportedly, large financial institutions typically run a few hundred systems, typically about two hundred, constantly and simultaneously to determine the price parameter functions and process the counterparty credit risk metrics.
The approximate total computational time of Step 204 is given by:computational time per calculation×number of derivatives,D×number of scenarios,N×number of time points,M number of computersAssuming that an average computational time for a price parameter function is only 0.01 seconds, taking the typical values above, this gives:
                    ⁢                            0.01          ×          1          ,          000          ,          000          ×          1          ,          000          ×          25                200            =                        1          ,          250          ,          000          ⁢                                          ⁢          seconds                ≈                  14.5          ⁢                                          ⁢          days                                        0.01        ×        1        ,        000        ,        000        ×        10        ,        000        ×        100            200        =                  50        ,        000        ,        000        ⁢                                  ⁢        seconds            ≈              578.7        ⁢                                  ⁢        days            
Therefore the computational time of Step 204 can easily range from 14.5 days to 578.7 days.
The vast number of determinations of the price parameter function 156 by the price parameter function evaluator 152 means that by the time the calculations are complete, the results may no longer be valid or useful. Therefore, financial institutions implement the forecasting system 100 in state-of-the-art computer farms but generally reduce the accuracy in order to save time. Further, in order to achieve the best possible result in the available time, workarounds are implemented including:
1) Reducing the number of scenarios and time points so the calculation can be done in a reasonable time. As a result, the quality of the risk metrics and subsequent risk management results generated by the forecasting system 100 substantially decreases.
2) Simply not attempting this calculation for sophisticated OTC derivatives with complex price parameter functions, as these would utilise more computational time. Again, as a consequence, risk management results are negatively affected.
3) Increasing the number of computers (and hence computational power) configured to implement the forecasting system 100. However, the number of computers required to reduce the time required to ensure that the results are valid and useful is impractical. Further, the size of the computational problem is so large that additional computing power can actually make a negligible difference to the time required.4) Implement methodological shortcuts in the calculation that may increase the speed, but that always create lack of accuracy in the calculation and, hence, decrease the usability of the metrics produced.
The present invention seeks to mitigate or at least overcome at least some of the above-mentioned problems.